1. Field of the Invention
This invention relates to communication and data processing technology, and more particularly to an efficient request-reply protocol for a client-server communication and data processing model.
2. Description of Related Art
In recent architectures for data communication and data processing technologies, many user workstations are typically interconnected by a computer network. The network may be of the direct connection type (e.g., LAN or WAN) or a wireless type, or a combination of both.
Among current designs for such architectures, the "client-server" model has become a typical model in which computers on the network communicate with each other. A typical client-server interaction involves a client computer requesting a server computer to perform a certain operation, whereupon the server performs the operation and conveys the result back to the client.
Currently, there are two basic types of protocols used by the client and server to communicate with each other based on the two pacing parameters of this architecture--network performance and server performance. Network performance varies with, among other things, network reliability and load. Server performance varies with, among other things, load and operation complexity.
FIG. 1 is a ladder diagram showing the flow and timing of communications between a client-server system according to a first prior art protocol. This protocol takes a "pessimistic" view of network characteristics. As shown, a Request is initially transmitted by a client 10 to a server 12 over a communication network. The server 12 responds with an Acknowledge. The Acknowledge must be received by the client 10 within a first elapsed time period TIMEOUT.sub.REQUEST or an error occurs. Such an error may represent, for example, a disruption or failure by the server 12 or in the network. If the client 10 does not receive the Acknowledge before the TIMEOUT.sub.REQUEST time elapses, the client 10 retransmits the Request until the client 10 receives an Acknowledge. The timer value, TIMEOUT.sub.REQUEST, is a function principally of the network characteristics. That is, the timer value is based upon some estimate as to how long an Acknowledge should take to be sent to the client 10 by the server 12.
After completing the requested operation, the server 12 responds back to the client with a Reply containing the result of the operation. If the client 10 does not receive the Reply within a second elapsed time period TIMEOUT.sub.REPLY, measured from the receipt of the Acknowledge, the client 10 conveys an error to higher layers of the application software executing within the client 10. The timer value TIMEOUT.sub.REPLY is a function of a time estimate as to how long the server 12 should take to perform the desired operation.
The biggest advantage of this protocol is the separation of the network and the server 12 performance variables, so even if the server 12 takes a longer time to reply than expected, only 3 protocol data units (PDUs) are exchanged between the client 10 and the server 12 in the normal case. The problem with this protocol is that even for the best case scenario, where the Request is not lost by the underlying network, there is an extra Acknowledge. This extra PDU results in unnecessary wastage of network bandwidth, which usually is a very precious resource. This becomes more apparent in a wireless network, with many nodes competing for limited radio bandwidth.
FIGS. 2a and 2b are ladder diagrams showing the flow and timing of communications between a client-server system according to a second prior art protocol. This protocol takes an "optimistic" view of network characteristics. Again, a Request is initially transmitted by a client 10 to a server 12 over a communication network. A Reply is used to convey the result to the client 10. Since the Reply indirectly indicates receipt of the Request by the server 12, a separate Acknowledge signal directly indicating such is unnecessary. Thus, no separate Acknowledge is sent by the server 12. If the server 12 sends the Reply before a time period TIMEOUT elapses (i.e., the anticipated "normal" condition), only 2 PDUs are exchanged between the client 10 and the server 12, as shown in FIG. 2a. However, if the client 10 does not receive the Reply within the Timeout period, the client 10 retransmits the Request under the assumption that the prior Request was "lost" in the network.
Although this protocol is the most efficient for the best case scenario (only 2 PDUs exchanged), it behaves rather poorly when the operation performed on the server 12 takes a longer time than expected, as shown in FIG. 2b. When completion of the operation by the server 12 is delayed, the client 10 has no way to determine whether the Request was lost or whether the server 12 was delayed in completing the operation. The client 10 can only assume that the server 12 did not get the prior Request, and so retransmits the Request again. If the operation takes long enough, this can cause multiple retransmissions of the Request, resulting not only in wastage of the network bandwidth but possibly overloading the server 12 with more processing, which in turn could cause more delay in the operation being performed on the server 12.
Accordingly, it would be desirable to have a more efficient protocol for the client-server model in a data communication and processing system.
The present invention provides such an improved protocol.